This chapter covers the basics of keeping your system secure. It takes a quick look at
the primary defenses you need to protect yourself from unauthorized access through
telephone lines (modems), as well as some aspects of network connections. In addition, it
explains how to protect your user files and ensure password integrity.
This chapter doesn't bother with complex solutions that are difficult to implement
because they require a considerable amount of knowledge and apply only to a specific
configuration. Instead, it looks at basic security methods, most of which are downright
simple and effective.
The most commonly used method for breaking into a system either through a network, over
a modem connection, or sitting in front of a terminal is through weak passwords. Weak
(which means easily guessable) passwords are very common. When system users have such
passwords, even the best security systems cannot protect against intrusion.
If you are managing a system that has several users, implement a policy requiring users
to set their passwords at regular intervals (usually six to eight weeks is a good idea)
and to use non-English words. The best passwords are combinations of letters and numbers
that are not in the dictionary. Sometimes, though, having a policy against weak passwords
isn't enough. You may want to consider forcing stronger password usage by using public
domain or commercial software that checks potential passwords for susceptibility. These
packages are often available in source code, so you can compile them for Linux without a
problem.
What makes a strong password (one that is difficult to break)? Here are a few general
guidelines that many system administrators adhere to:
Producing a strong password isn't that difficult. Get your users into the habit of
mixing letters, numbers, and characters at random. Suppose a user wants to use lionking as
a password. Encourage modification to lion!king!, l_ionk_ing, lion5king, or some similar
variation. Even a slight variation in a password's normal pattern can make life very
difficult for someone trying to guess the password.
Change the root password often and make it very difficult to guess. Once someone has the root password, your system is totally compromised.
Check the /etc/passwd file at regular intervals to see whether there are entries you
don't recognize that may have been added as a route in to your system. Also make sure each
account has a password. Remove any accounts that you don't need anymore.
Security begins at the file permission level. Whether you want to protect a file from
the prying eyes of an unauthorized invader or another user, carefully set your umask (file
creation mask) to set your files for maximum security. You should have to make a conscious
effort to share files.
Of course, this precaution is really only important if you have more than one user on
the system or have to consider hiding information from others. If you are on a system with
several users, consider forcing umask settings for everyone that set read-and-write
permissions for the user only and give no permissions to anyone else. This procedure is as
good as you can get with file security.
Consider encrypting really sensitive files (such as accounting or employee information)
with a simple utility. Many such programs are available. Most require only a password to
trigger the encryption or decryption process.
For most Linux users, protecting the system from access through an Internet gateway
isn't important because few users have an Internet access machine directly connected to
their Linux box. Instead, the main concern should be to protect yourself from break-in
through the most accessible method open to system invaders: modems.
Modems are the most commonly used interface into every Linux system (unless you are
running completely stand-alone or on a closed network). Modems are used for remote user
access, as well as for network and Internet access. Securing your system's modem lines
from intrusion is simple and effective enough to stop casual browsers.
The safest technique to prevent unauthorized access through modems is to employ a
callback modem. A callback modem lets users connect to the system as usual, and then hangs
up and consults a list of valid users and their telephone numbers and calls back the user
to establish the call. Callback modems are quite expensive, so this solution is not
practical for many systems. Callback modems have some problems, too, especially if users
change locations frequently. Also, callback modems are vulnerable to abuse because of
call-forwarding features of modern telephone switches.
The typical telephone modem can be a source of problems if it doesn't hang up the line
properly after a user session has finished. Most often, this problem stems from the wiring
of the modem or the configuration setup.
Wiring problems may sound trivial, but many systems with hand-wired modem cables don't
properly control all the pins; the system can be left with a modem session not properly
closed and a log-off not completed. Anyone calling that modem continues where the last
user ended. To prevent this kind of problem, make sure the cables connecting the modem to
the Linux machine are complete. Replace hand-wired cables that you are unsure of with
properly constructed commercial ones. Also, watch the modem when a few sessions are
completed to make sure the line hangs up properly.
Configuration problems can also prevent line hangups. Check the modem documentation to
make sure your Linux script can hang up the telephone line when the connection is broken.
This problem seldom occurs with the most commonly used modems, but off-brand modems that
do not have true compatibility with a supported modem can cause problems. Again, watch the
modem after a call to make sure that it is hanging up properly.
One way to prevent break-ins is to remove the modem from the circuit when it's not
needed. Because unwanted intruders usually attempt to access systems through modems after
normal business hours, you can control the serial ports the modems are connected to by
using cron to change the status of the ports or disable the port completely after hours.
If late-night access is required, one or two modem lines out of a pool can be kept active.
Some larger systems keep a dedicated number for the after-hours modem line, usually
different than the normal modem line numbers.
For a user to gain access to Linux through a modem line, the system must use the getty
process. The getty process itself is spawned by the init process for each serial line. The
getty program is responsible for getting usernames, setting communications parameters
(baud rate and terminal mode, for example), and controlling time-outs. In Linux, the
/etc/ttys file controls the serial and multiport board ports.
Some Linux systems allow a dialup password system to be implemented. This kind of
system forces a user calling on a modem to enter a second password that validates access
through the modem. If this feature is supported on your system, it is usually with a file
called /etc/dialups. The Linux system uses the file /etc/dialups to supply a list of ports
that offer dialup passwords; a second file (such as /etc/d_passwd) has the passwords for
the modem lines. Access is determined by the type of shell used by the user. You can apply
the same procedure to UUCP access.
The UUCP (Unix to Unix CoPy) program allows two Linux systems to send files and e-mail
back and forth (see Chapter 27, "UUCP"). Although this
program was designed with good security in mind, it was designed many years ago and
security requirements have changed a lot since then. A number of security problems have
been found over the years with UUCP, many of which have been addressed with changes and
patches to the system. Still, UUCP requires some system administration attention to ensure
that it is working properly and securely.
UUCP has its own password entry in the system password file /etc/passwd. Remote systems
dialing in using UUCP log in to the local system by supplying the uucp login name and
password. If you don't put a password on the system for the UUCP login, anyone can access
the system. One of the first things you should do is log in as root and issue the command
passwd uucp
to set a UUCP password. If you want remote systems to connect through UUCP, you have to
supply them with your password, so make sure it is different than other passwords (as well
as difficult to guess). The slight hassle of having to supply passwords to a remote system
administrator is much better than having a wide-open system.
Alternatively, if you don't plan to use UUCP, remove the uucp user entirely from the
/etc/password file or provide a strong password that can't be guessed (putting an asterisk
as the first character of the password field in /etc/passwd effectively disables the
login). Removing uucp from the /etc/passwd file doesn't affect anything else on the Linux
system.
Set permissions to be as restrictive as possible in all UUCP directories (usually
/usr/lib/uucp, /usr/spool/uucp, and /usr/spool/uucppublic). Permissions for these
directories tend to be lax with most systems, so use chown, chmod, and chgrp to restrict
access only to the uucp login. Set the group and username for all files to uucp as well.
Check the file permissions regularly.
UUCP uses several files to control who is allowed in. These files
(/usr/lib/uucp/Systems and /usr/lib/uucp/Permissions, for example) should be owned and
accessible only by the uucp login. This setup prevents modification by an intruder with
another login name.
The /usr/spool/uucppublic directory can be a common target for break-ins because it
requires read and write access by all systems accessing it. To safeguard this directory,
create two subdirectories: one for receiving files and another for sending. You can create
more subdirectories for each system that is on the valid user list, if you want to go that
far.
A neat trick to protect UUCP is to change the UUCP program login name so that random
accessing to the uucp login doesn't work at all. The new name can be anything, and because
valid remote systems must have a configuration file at both ends of the connection, you
can easily let the remote system's administrator know the new name of the login. Then no
one can use the uucp login for access.
Most LANs are not thought of as a security problem, but they tend to be one of the
easiest methods into a system. If any of the machines on the network has a weak access
point, all the machines on the network can be accessed through that machine's network
services. PCs and Macintoshes usually have little security, especially over call-in
modems, so they can be used in a similar manner to access the network services. A basic
rule about LANsis that it is impossible to have a secure machine on the same network as
non-secure machines. Therefore, any solution for one machine must be implemented for all
machines on the network.
The ideal LAN security system forces proper authentication of any connection, including
the machine name and the username. A few software problems can contribute to
authentication difficulties. The concept of a trusted host, which is implemented in Linux,
allows a machine to connect without hassle assuming its name is in a file on the host
(Linux) machine. A password isn't even required in most cases! All an intruder has to do
is determine the name of a trusted host and then connect with that name. Carefully check
the /etc/hosts.equiv, /etc/hosts, and .rhosts files for entries that may cause problems.
One network authentication solution that is now widely used is Kerberos, a method
originally developed at MIT. Kerberos uses a very secure host that acts as an
authentication server. Using encryption in the messages between machines to prevent
intruders from examining headers, Kerberos authenticates all messages over the network.
Because of the nature of most networks, most Linux systems are vulnerable to a
knowledgeable intruder. There are literally hundreds of known problems with utilities in
the TCP/IP family. A good first step to securing a system is to disable the TCP/IP
services you don't use at all, as others can use them to access your system.
Many intruders are curious about your system but don't want to do any damage. They may
get on your system with some regularity, snoop around, play a few games, and then leave
without changing anything. This activity makes it hard to know you are being broken into
and leaves you at the intruder's mercy should he decide he wants to cause damage or use
your system to springboard to another.
You can track users of your system quite easily by invoking auditing, a process that
logs every time a user connects and disconnects from your system. Auditing can also tell
you what the user does while on your system, although this type of audit slows the system
down a little and creates large log files. Not all Linux versions support auditing, so
consult your man pages and system documentation for more information.
If you do rely on auditing, scan the logs often. It may be worthwhile writing a quick
summary script program that totals the amount of time each user is on the system so that
you can watch for anomalies and numbers that don't mesh with your personal knowledge of
the user's connect times. You can write a simple shell script to analyze the log in gawk.
You can also use one of the audit reporting systems available in the public domain.
If someone does break in to your system, what can you do? Obviously, backups of the
system are a help, as they let you recover any damaged or deleted files. But beyond that,
what should you do?
First, find out how the invader got in and secure that method of access so it can't be
used again. If you are not sure of the access method, close down all modems and terminals
and carefully check all the configuration and setup files for holes. Also check passwords
and user lists for weak or outdated material.
If you are the victim of repeated attacks, consider enabling an audit system to keep
track of how intruders get in and what they do. If you are concerned about damage, force
off any intruders as soon as you see them log in.
Lastly, if the break-ins continue, call the local authorities. Breaking into computer
systems (whether a large corporation or your own home system) is illegal in most
countries, and the authorities will usually know how to trace the intruders back to their
calling points. They're breaking into your system and shouldn't get away with it!
For most Linux systems, security isn't an issue because you are the only one who is using the machine. If, however, you share your machine with others or make it available for on-line access to anyone on the network (or the Internet), don't underestimate the chances of someone trying to break in; they will. Make your system as secure as you can. Common sense helps a lot, but don't forget that hackers are a wily, industrious, and tenacious bunch.
